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EXAMINER'S ANSWER 



This is in response to the supplemental appeal brief filed 4-20-2006. 
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( 1) Real Party in Interest 

A statement identifying the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The following are the related appeals, interferences, and judicial proceedings 
known to the examiner which may be related to, directly affect or be directly affected by 
or have a bearing on the Board's decision in the pending appeal: 

- 09/870,61 3: Notice of Appeal filed 2/7/05; Appeal Brief filed April 7, 2005. 

- 09/870,614: Notice of Appeal filed 10/26/04; Appeal Brief filed 

December 20, 2004. 

- 09/870,615: Notice of Appeal filed 9/14/04; Appeal Brief filed 

November 9, 2004. 

- 09/870,621 : Notice of Appeal filed 9/24/04; Appeal Brief filed 

November 23, 2004. 

- 09/870,622: Notice of Appeal filed 8/24/04; Appeal Brief filed October 25, 2004. 

- 09/870,624: Notice of Appeal filed 5/23/05; Appeal Brief filed July 25, 2005. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 
No amendment after final has been filed. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 
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(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

Nelson, Matthew T., Java Foundation Classes, 1998, McGraw-Hill, xxv-xxvii, 20-22, 
43, 73-79, 472-481, 694-707 

6,005,588 Guha 12-1999 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claims 1, 3-10, and 12-17 are rejected under 35 U.S.C. 103(a) as being 

unpatentable over Nelson, Java Foundation Classes, hereinafter Nelson. This rejection 

is set forth in a prior Office Action, mailed on 2-7-05. 

Claims 2 and 1 1 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

Nelson, Java Foundation Classes, and Guha, patent #6,005,588. This rejection is set 

forth in a prior Office Action, mailed on 2-7-05. 



(10) Response to Argument 
Claims 1, 3-10, and 12-16; 
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With respect to the group of claims including Claims 1, 3-10, and 12-16, the 
Appellant's arguments are focused on the limitations regarding a first software 
component for creating a graphical representation of an object, and define visual 
attributes, and a second software component that draws the text. More specifically, as 
stated from representative Claim 1, the limitation argued is: 

a first software component adapted to create a graphical representation of 
an object embodied as code within the software component, 
wherein the code comprises text and other displayable content; 
an application program running under an operating system; and 
a second software component adapted for drawing the text, wherein the 
first software component is invoked during runtime by the 
application program to define visual attributes of the text, but not to 
draw the text, and wherein the second software component is 
invoked to draw the text using the visual attributes. 
Since the interpretation of the limitation is the basis for the arguments, the Examiner's 
interpretation is now given. The Examiner asserts the limitation to be a computer 
readable medium in which a first software component defines visual attributes of text, 
but does not draw the text; a second software component then draws the defined text. 

As stated in the eighth paragraph of MPEP 2101[R2].II.C, 
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"Office personnel are to give claims their broadest reasonable 
interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 
1048, 1054-55, 44 USPQ2d 1023,1027-28 (Fed. Cir. 1997)." 

Based on the interpretation of the claim limitations being argued, the 
Examiner will now explain how the teachings of the references, are within the 
scope of these limitations. 

- Nelson teaches a system in which a ill class (second software component) 
draws text components, but doesn't know what the text control contains or 
what the content s should look like, so it gets the Document using the Text 
Component's getDocumentQ or getStyledDocumentQ method (first software 
component) (see page 78, under the "Interacting with Documents" heading). 
Nelson further teaches Documents containing Elements that comprise a 
mapping of Document characters to attributes, these attributes defining how a 
document text should look (see page 73 all). The Interacting with the Ul" 
heading further shows that "the Ul class retrieves each Element from the 
Document and creates a View that knows how to draw each one." 

Before answering individual argument the examiner would like to point out 
several points that the applicant has admitted to in the appeal brief and prior 
submission. 
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- the Amendment filed on 5-17-04, on page 1 1, in the first paragraph, the 
applicant points out that "The Applicant agrees that separate groups of 
Swing-based code may be used for setting the look-and-feel of a displayed 
object and for drawing text within or upon the displayed object. For example, 
the "setLookAndFeel" method is commonly used to define the look-and-feel of 
a text field (and even the associated text) drawn by the JtextField 
Component" To this the examiner agrees that separate groups of code can 
be used for setting the look-and-feel and for drawing the text This is what the 
examiner believes to be a major claimed inventive feature of the claimed 
invention. 

- The Appeal Brief filed 2-11-04, on page 5, from the third paragraph, ". . . the 
getDocumentQ and getStyledDocumentQ methods are not used for drawing 
the text attributable to a Text Component, but instead merely for accessing or 
fetching a document (or styled document) associated with the Text 
Component These methods are embodied within the Text Component, and 
may be used by a Swing ill class to get the document (or styled document) 
when it is time for the Swing ill class to draw the Text Component. See, e.g., 
Nelson, page78, under the heading of "Interacting with Text Componets". 
Since the getDocumentQ and getStyledDocumentQ methods (as described on 
page 78 of Nelson) are not used for actually drawing the text, the methods 
cannot be considered equivalent to the presently claimed second software 
component" To this, the examiner agrees that it cannot be considered the 
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second software component, because it is the first software component that 
defines the look-and-feel and does not draw the component. 

The examiner will now address the individual arguments and statements made by the 
Appellant. 

From page 4 of the Appeal Brief, from the first paragraph, the Appellant 
argues "Nelson, however, does not teach or suggest a first software component 
that is adapted to: (i) create a graphical representation of an object embodied by 
code, which includes text and other displayable content, and define visual 
attributes of the text without drawing the text." 

The examiner contends that the Nelson reference teaches on page 78, a Ul class 
(second software component) having separate groups of code to get the look-and-feel, 
and to draw the text, it teaches a Ul class that doesn't know what the text control 
contains or what the contents should look like, but uses getDocument() or 
getStyledDocument() methods (first software component). As if further shown on page 
73, the Ul class (second software component) retrieves each Element from the 
Document (first software component) and creates a View that knows how to draw each 
one. The Document is shown to contain visual attributes, on page 73, where Nelson 
teaches that the Document contains Elements that have Attributes defining how text 
should look. The appellant further admits in ihe Appeal Brief filed 2-11-04, on page 8 
and 9, from the last paragraph of page 8, "... the getDocumentQ and 



Application/Control Number: 09/870,620 Page 8 

Art Unit: 2173 

getStyledDocumentQ methods are not used for drawing the text attributable to a Text 
Component, but instead merely for accessing or fetching a document (or styled 
document) associated with the Text Component 

From page 5 of the Appeal Brief, from the second paragraph, the 
Appellant argues "the Examiner appears to suggest that a Swing Ul class may be 
used to "get the look-and-feel" of a text component, while the getDocument() and 
getStyledDocument() methods may be used for drawing the text attributable to 
the Text Component. Therefore, the Examiner appears to rely on a Swing Ul 
class to provide teaching for the presently claimed first software component and 
the getDocument() and getStyledDocument() methods to provide teaching for the 
presently claimed second software component." 

The examiner contends that the Appelant is incorrect in this assertion as can be 
see though the answer to the arguments in the final action where the Examiner pointed 
out that "Nelson teaches on page 78, Ul class having separate groups of code to get the 
look-and-feel, and to draw the text. It teaches a Ul class that doesn't know what the text 
control contains or what the contents should look like, but uses getDocument() or 
getStyledDocument() methods." The examiner, in this instance, interprets the Ul class 
to be the Second Software Component an the getDocument() or getStyledDocument() 
methods to be the First Software Component. 
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From page 6 of the Appeal Brief, from the second paragraph, the 
Appellant argues "the Ul class of Nelson does not include 'code comprising text 
and other displayable content' ". 

The examiner contends that the office interperets the Ul class to be the Second 
Software Component an the getDocument() or getStyledDocument() methods to be the 
First Software Component. Where the appellant is correct, in this instance, that the Ul 
class does not include 'code comprising text and other displayable content.' The 
getDocumentO or getStyledDocument() methods, however, as shown supra do include 
'code comprising text and other displayable content.' 

From page 6 of the Appeal Brief, from the third paragraph, the Appellant 
argues "The appellants are confused as to how a 'constructor that is able to 
transfer a complete document from on text component to another' can be used to 
provide teaching for the presently claimed first software component. Transfering 
a complete document from one text component to another is not a claimed 
feature of the invention." 

The examiner contends that the statement as presented is not relied upon for the 
teaching of a first software component but merely to show the transferring of information 
between components. 
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From page 7 of the Appeal Brief, from the third paragraph, the Appellant 
argues "There is no motivation to modify the teachings of Nelson to provide the 
presently claimed first software component". 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, the Nelson 
reference teaches on page 78 and on page 73, Ul class (second software component) 
having separate groups of code to get the look-and-feel, and to draw the text, it teaches 
a Ul class that doesn't know what the text control contains or what the contents should 
look like, but uses getDocument() or getStyledDocument() methods (first software 
component). The appellant further admits in the Appeal Brief filed 2-11-04, on page 8 
and 9, from the last paragraph of page 8, "... the getDocumentQ and 
getStyledDocumentQ methods are not used for drawing the text attributable to a Text 
Component, but instead merely for accessing or fetching a document (or styled 
document) associated with the Text Component 
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From pages 7 (paragraph 5) through page 8 (paragraph 3) of the Appeal 
Brief, the Appellant argues "the combination of JtextField and Jlable 
components". 

The examiner contends that this is not the combination of components that the 
examiner wished to treat as the First and Second Software components, in claim 1. 
The examiner, in this instance, interprets the Ul class to be the Second Software 
Component an the getDocument() or getStyledDocument() methods to be the First 
Software Component. 

From page 8 of the Appeal Brief, from the fourth paragraph, the Appellant 
argues "The Examiner has failed to adequately support and/or establish prima 
facie grounds of obviousness". 

In response to applicant's argument that there is no teaching or motivation to 
suggest the aforementioned limitations of present claim 1 , the test for obviousness is 
not whether the features of a secondary reference may be bodily incorporated into the 
structure of the primary reference; nor is it that the claimed invention must be expressly 
suggested in any one or all of the references. Rather, the test is what the combined 
teachings of the references would have suggested to those of ordinary skill in the art. 
See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 
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Claim 17: 

With respect to the group of claims including Claim 17, the Appellant's arguments 
are focused on the limitations regarding a peer component for redirecting a call between 
software components. More specifically, as stated from representative Claim 17, the 
limitation argued is: 

a peer component adapted for redirecting a memory call to invoke text 
drawing methods of the second software component rather than 
text drawing methods of the first software component 
Since the interpretation of the limitation is the basis for the arguments, the Examiner's 
interpretation is now given. The Examiner asserts the limitation to be an element that 
redirects a call to invoke text drawing methods of the second software component rather 
than text drawing methods of the first software component 

As stated in the eighth paragraph of MPEP 2101[R2].II.C., 

"Office personnel are to give claims their broadest reasonable 
interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 
1048, 1054-55, 44 USPQ2d 1023,1027-28 (Fed. Cir. 1997)." 

Based on the interpretation of the claim limitations being argued, the 
Examiner will now explain how the teachings of the references, are within the 
scope of these limitations. 
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- Nelson teaches a system in which a ill class (second software 
component) draws text components, but doesn't know what the text 
control contains or what the content s should look link, so it gets the 
Document using the Text Components getDocumentQ or 
getStyledDocumentQ method (first software component) (see page 
78, under the "Interacting with Documents" heading). Nelson further 
teaches Documents containing Elements that comprise a mapping of 
Document characters to attributes, these attributes defining how a 
document text should look (see page 73 all). The "Interacting with the 
ill" heading further shows that "the Ul class retrieves each Element 
from the Document and creates a View that knows how to draw each 
one. 

The examiner will now address the individual arguments and statements made by the 
Appellant. 

From page 9 of the Appeal Brief, from the sixth paragraph, the Appellant 
argues "Nelson fails to provide teaching, suggestion, or motivation for a peer 
component, which redirects a call to invoke the text drawing methods of the 
second software component rather than the text drawing methods of the first 
software component". 
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The examiner contends that the Nelson teaches, on pages 694, 697, 472, and on 
page 72, a system for drawing text where one component can define attributes of an 
item and the actual displaying of the item can be implemented by another item. It is, 
however, a design choice, an item could just as easily be given attributes and drawn by 
the same software component. Similarly, the system of Nelson, on page 73, allows a 
software component to reference a Document to provide the Element and 
corresponding Attributes, but not to draw; and then directs the text attributes to the Ul 
class, for drawing to the display. "Interacting with Document" on page 73, points out 
that a Document might be asked for the Element and returning. In this sense the 
Document acts as a peer component that access the Element an provides look-and-feel 
information back to the Ul class. 

From page 10 of the Appeal Brief, from the third paragraph, the Appellant 
argues "There is no motivation to modify the teachings of Nelson to provide the 
presently claimed peer component". 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, the Nelson 
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reference teaches on page 78 and on page 73, Ul class (second software component) 
having separate groups of code to get the look-and-feel, and to draw the text, it teaches 
a Ul class that doesn't know what the text control contains or what the contents should 
look like, but uses getDocument() or getStyledDocument() methods (first software 
component). The appellant further admits in the Appeal Brief filed 2-11-04, on page 8 
and 9, from the last paragraph of page 8, "... the getDocumentQ and 
getStyledDocumentQ methods are not used for drawing the text attributable to a Text 
Component, but instead merely for accessing or fetching a document (or styled 
document) associated with the Text Component. 

From page 10 of the Appeal Brief, from the fifth paragraph, the Appellant 
argues "The Examiner has failed to adequately support and/or establish prima 
facie grounds of obviousness". 

In response to applicant's argument that there is no teaching or motivation to 
suggest the aforementioned limitations of present claim 17, the test for obviousness is 
not whether the features of a secondary reference may be bodily incorporated into the 
structure of the primary reference; nor is it that the claimed invention must be expressly 
suggested in any one or all of the references. Rather, the test is what the combined 
teachings of the references would have suggested to those of ordinary skill in the art. 
See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

Claims 2 and 11: 
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With respect to the group of claims including Claims 2 and 1 1 , the Appellant's 
arguments are focused on the limitations regarding a first software component for 
creating a graphical representation of an object, and define visual attributes, and a 
second software component that draws the text (as previously argued). More 
specifically, as stated from representative Claim 1, the limitation argued is: 

a first software component adapted to create a graphical representation of 
an object embodied as code within the software component, 
wherein the code comprises text and other displayable content; 
an application program running under an operating system; and 
a second software component adapted for drawing the text, wherein the 
first software component is invoked during runtime by the 
application program to define visual attributes of the text, but not to 
draw the text, and wherein the second software component is 
invoked to draw the text using the visual attributes. 
Based on the interpretation of the claim limitations being argued, the Examiner 
will now explain how the teachings of the references, are within the scope of 
these limitations. 

- Nelson teaches a system in which a Ul class (second software 
component) draws text components, but doesn't know what the text 
control contains or what the content s should look like, so it gets the 
Document using the Text Components getDocumentQ or 
getStyledDocumentQ method (first software component) (see page 
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78, under the "Interacting with Documents" heading). Nelson further 
teaches Documents containing Elements that comprise a mapping of 
Document characters to attributes, these attributes defining how a 
document text should look (see page 73 all). The "Interacting with the 
Lir heading further shows that "the ill class retrieves each Element 
from the Document and creates a View that knows how to draw each 
one." 

- Guha teaches a system of rapidly displaying text as did Nelson but 
further teaches, in column 2, lines 14-45, placing characters in a 
bitmap in memory, where there pixels are combined into lines to 
reduce the amount of memory space required to store 

The examiner will now address the individual arguments and statements made by the 
Appellant. 

From page 1 1 of the Appeal Brief, from the fifth paragraph, the Appellant 
argues that although Guha is not cited against the present claims 1 and 8, Guha 
cannot be combined with Nelson to teach or suggest the presently claimed first 
software component; and a combination would not overcome the deficiencies 
therein. 

The examiner contends that there are no deficiencies to overcome and that the 
Nelson reference teaches on page 78, Ul class (second software component) having 
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separate groups of code to get the look-and-feel, and to draw the text, it teaches a Ul 
class that doesn't know what the text control contains or what the contents should look 
like, but uses getDocument() or getStyledDocument() methods (first software 
component). As if further shown on page 73, the Ul class (second software component) 
retrieves each Element from the Document (first software component) and creates a 
View that knows how to draw each one. The Document is shown to contain visual 
attributes, on page 73, where Nelson teaches that the Document contains Elements that 
have Attributes defining how text should look. The appellant further admits in the 
Appeal Brief filed 2-11-04, on page 8 and 9, from the last paragraph of page 8, "... the 
getDocumentQ and getStyledDocumentQ methods are not used for drawing the text 
attributable to a Text Component, but instead merely for accessing or fetching a 
document (or styled document) associated with the Text Component. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 
For the above reasons, it is believed that the rejections should be sustained. 
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For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 



Kristine Kincaid 
Supervisory Patent Examiner 
June 16, 2006 
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